Perhaps explain why? We don't do this with other features afaik?

I think we do do feature detection in some places.

The reason we want both approaches in this case is kind of important. There are two main cases:

1. For all users or pthreads+memory growth we probably want to use toResizableBuffer when available in all cases. It slightly fast since we don't need to rebuild the views each time the memory grows. There is very little cost to probing for, and using the features if its found.

2. For users that know that they are only targetting newer browsers they can opt in with -sGROWABLE_ARRAYBUFFERS which means we don't need run the whole growableHeap JS optimizer path (which is the thing that slows down all the HEAP accesses in normal builder). These users see even more of a benefit, but their code won't run on older browsers.

For example of where we do feature detection you can see many by doing git grep "if .*globalThis" src.

In most cases we don't have setting to opt out of the feature-detection and just assume the feature is present. In some cases we can use the feature matrix to detect when the feature-detection is not needed.

In the long run I think we may just want to delete this setting (or at least make it internal) since it can be driven completely by the feature matrix.

For example of where we do feature detection you can see many by doing git grep "if .*globalThis" src.

Do we have feature flags for those things, though? E.g. one result is

src/lib/libembind.js:    if (!globalThis.FinalizationRegistry) {

I don't think we have a flag for that, so we have to check it.

That is, what seems new to me is Even when this setting is disabled, Emscripten will still use this feature when available - do we do that anywhere else? Normally if a user disables a setting, we don't use the feature, afaik

For this feature I think we want two things:

1. We want to use it whenever we can. There is really no need to be able to completely opt out. (just like with FinalizationRegistry).
2. We want to be able to create a built where we assume its always present (because we want to be able to opt out of the cost of using growableHeap JS transform.

We maybe its not something we have done before (both features detection and a setting). But I certainly think its justified in this case.

Unless you have any other ideas about how to better take advantage of this by default?

Maybe I'm over excited about not having to ever re-create the memory views. Given that modern browsers can avoid it, it just seems ergonomic to do it.

It also has some other nice side benefits like if users store memory views anywhere or pass them around the they continue to work and grow. Right now any such stored view will be broken on memory growth.

I guess its just seems like such nice simplification to me, but you are right that it comes with a small code size hit.

I'm also hoping we can simply remove the emscripten_notify_memory_growth mechanism that we have in place to support PUSE_WASI.. maybe maybe we should just remove the PURE_WASI stuff instead?

Yeah, I guess I am not sure if this is worth the benefit or not. I can see arguments both ways. Definitely this avoids some bugs in user JS code, as you say... Have we seen users hit such bugs, do you remember?

About PURE_WASI, maybe we can make that mode not support JS, that is, pure WASI only runs in WASI environments? It is supporting pure WASI in JS that makes things hard and need that growth callback.

Part of my original idea for PURE_WASI was that you could do ./emcc -sPURE_WASI --post-link <some_file>.wasm as a way to run the wasi file on the web.

That never really panned out though.

Reading the below Firefox bug report, I think this comment should be adjusted to something like:

(i.e. wasmMemory.toResizableBuffer() works as expected, but it cannot be deserialized in web workers.)

How about turning this into a three-mode setting, similar to -sTEXTDECODER? That would give us:

• -sGROWABLE_ARRAYBUFFERS=0 - current default: the generated code will not use a growable SharedArrayBuffer.
• -sGROWABLE_ARRAYBUFFERS=1 - potential new default: the generated code will use a growable SharedArrayBuffer when available and supported.
• -sGROWABLE_ARRAYBUFFERS=2 - assumes the WebAssembly.Memory.toResizableBuffer() API is available and usable and omits any JS fallback code.

Oh sorry, I just noticed this is also mentioned in #27096 (comment).

Good idea. Lets do that.

BTW, we default to =1 for TEXTDECODER, which means "feature detect with fallback", so this is great analogy to what we have here.